In third-party publication applications, the document owner produces documents and allows third parties to publish them so that the documents can be widely disseminated. The publishers respond to the requests of the users by sending appropriate data. The requested data arriving at the user may only be a portion of the complete document generated by the owner. There may be two reasons for this. One is that the user requests for only part of the document while the other is that due to the limitation of network bandwidth, access privilege or receiver resource, a proxy transcodes the data sent from the publisher so that different users can have different quality of content. For example, a client (user) may request for half the number of the tiles of an original JPEG2000 image according to JPIP protocol. A proxy may then transmit to the client only the lowest resolution of the code-stream sent from the server on account of the limitation of network bandwidth.
In critical applications, the user may need a proof of authenticity of the content, so as to assure that the content is authentic. These applications may arise in various sectors such as the government, finance, healthcare and law sectors. Therefore, a solution is required for transmitting authentic portions of an authenticated document.
One solution would be ensuring the document owner prepares all possible signatures for all possible answers to users' requests in advance. However, this solution is not scalable and impractical when there are many different users' requests. Another solution would be to provide a designated server that certifies answers to users' requests by digitally signing them with an on-line private key. However, the server and its on-line private key, would be vulnerable to external hacking and insider attacks. The server needs to be trusted, and it needs to maintain an on-line signing key. Thus, both suggested solutions will not be feasible for transmitting authentic portions of an authenticated document. Therefore, some other approaches may also be considered here.
An approach to sign XML documents has been suggested which allows untrusted servers to answer certain types of requests over XML documents without the need for trusted on-line signing keys. XML is a tree-like data structure in nature. It admits a hash procedure which basically hashes the leaves of the document, and recursively proceeds up the document tree, hashing both the element types as well as the elements within the document. If the root hash of an entire document is known to a verifier, it is possible to provide evidence of a sub-tree to the verifier when the hash values of its siblings and the siblings of all its parents are available. The proposed signature approach allows the use of a single signature over an entire document to authenticate any given part of that document by introducing an auxiliary structure. However, the author does not disclose any treatment regarding documents whose data structures are represented with multiple trees.
On the other hand, U.S. Pat. No. 5,694,569 permits the hash of a file to be taken on an incremental basis. It permits any part of the file to be changed while allowing a new aggregate hash to be computed based on the revised file portion and the prior hash. With a commutative, invertible and associative function such as exclusive OR and arithmetic addition, the aggregate hash is readily updated with each record revision without re-computing the hash of the entire file. All such record hashes are added together. It was believed that the aggregate hash covers the entire database such that the tampering of any data record is revealed. Unfortunately, this incremental hash scheme was broken recently.
On a similar note, U.S. Pat. No. 5,898,779 discloses a digital camera having embedded therein a unique private key. Within the image captured with the designated camera, at least one region of interest (ROI) suitable for authentication can be identified. A signature can be generated on the hash value of the ROI. The image data, the digital signature, and the location data of said ROI are stored in a digital record. A known public key corresponding to the private key is used to check the signature to establish authenticity of the ROI. However, a problem arises since the ROI cannot be varied or changed once the digital signature is generated.
Hence, it is with the knowledge of the above concerns and restrictions that the present invention has been made.